8bitfiles.net/archives/archives.tar/archives/compuserve-file-archive/23 Geos Applications/GEOREU.THD

Text File | 2019-04-13 | 17KB | 459 lines

#: 17382 S13/The GEOS Connection
    27-Dec-88  09:33:33
Sb: #REU help needed
Fm: Bob Clemens 76337,3532
To: All

     I need some help using my new 1764 REU with GEOS 2.0.  I've read and
re-read the GEOS manual, the 1764 manual, and excerpts from magazine articles.
But I still do not entirely understand what I'm doing.
     What success I have had is by configuring the 1764 as a "shadow drive"
under the Drive A options and toggling "on" the RAM reboot and MoveData options
in the RAM Expansion 256K box.
     With this configuration, booting of the System disk and first loading of
subsequent disks and their files seems normal, but all additional loads and
activities are much faster (one text file in geoWrite took 21 seconds to load
the first time; only 6 seconds thereafter; "Quit" took 20 seconds the first
time, 4 seconds after).
     But I still feel I'm not fullly understanding what's happening.  And I'm
completely baffled when I attempt to use the 1764 as Drive B.  Is the 1764 copy
program a method of loading the REU with needed material?  I tried this, but
when I accessed Drive B in GEOS, only an empty desktop appeared. How do you get
a directory listing for the REU as device 9?? Is there a preferred
configuration for using the REU with GEOS?
     The list of questions could go on.  Seems to me we need a GOOD text file
here on CIS that would take dummies like me through the use of the 1764, since
I suspect I'm not alone in being lost and confused by the "instructions"
provided by either CBM or BSW (bless their inept little hearts), and I'm
certain more and more C64 users will be getting REU's as time goes on.
     Any help will be much appreciated.  Thanks.

                                                               Bob Clemens



#: 17385 S13/The GEOS Connection
    27-Dec-88  11:24:17
Sb: #17382-#REU help needed
Fm: Marte Brengle 76703,4242
To: Bob Clemens 76337,3532 (X)

Bob, I left you a message on CBMCOM about this.  I have an article I wrote for
GEOWORLD a while back about REUs, and I will see about re-writing it and upload
it here to the GEOS Library.  I'm not sure it explains *everything* but it may
give you a start.

                                                         --M--




#: 17395 S13/The GEOS Connection
    27-Dec-88  18:45:16
Sb: #17385-REU help needed
Fm: Bob Clemens 76337,3532
To: Marte Brengle 76703,4242 (X)

Marte,
     Sounds like a good start to me, Marte.  Thanks!

                                                                   Bob

#: 17391 S13/The GEOS Connection
    27-Dec-88  16:58:01
Sb: #17382-#REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: Bob Clemens 76337,3532 (X)

Bob,
   Let me see what I can add to what Marte's left for you in CBMCOM.  Her
article, by the way, was in Sept. 1987 geoWorld, if you're into back issues
<grin>.
   As she says, shadowing a disk is a form of what's known in the mainframe
world as "cacheing".   Imagine the REU standing between the real disk drive and
GEOS.  The first time a given sector of a given disk is read, it passes thru
the REU, and is recorded there.  Subsequent reads of that sector only have to
go as far as the REU.  Any sector being written to the disk goes thru the REU,
and reaches the disk.  Subsequent reads of that sector likewise only have to go
as far as the REU.
   Shadowing is most effective when working with programs and/or data that are
VLIR structured.  VLIR applications and application data (geoWrite and it's
documents and geoPaint and it's documents are good examples) frequently reread
previously read sectors.
   A RAM disk is easier to visualize.  The REU simply acts as if it were a
1541, albeit an amazingly fast one.  The trade-off here, of course, is that
when you power off, the contents of the disk are lost.  You have to remember to
eventually write everything you have changed, and wish to save, back to a real
disk.  Note that the REU memory is preserved for one or two seconds, and it
*may* be possible to recover from a very brief power off.
   When using a RAM disk, it is, as Marte says, necessary to write files to it.
Besides the individual copies, and the disk copy functions she points out, GEOS
2.0 also provides you with the option of multiple selection from keyboard
shortcuts.  This is touched on at the very bottom of page 63 of the manual, and
following.
   RAM Reboot and DMA for MoveData options are covered in item 7 on page 82.
These are both good things, and you'll normally leave them enabled.  It is
sometimes desirable to shut off RAM Reboot in GEOS 128, but I haven't found
this necessary in GEOS 64.
   Continued...


#: 17392 S13/The GEOS Connection
    27-Dec-88  17:03:35
Sb: #17391-#REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: [F] Bob Clemens 76337,3532 (X)

   ...Continued
   Figuring out the optimum way to use the REU in a given situation becomes an
intellectual challenge.  Because I frequently work on a relatively large number
of application data files at once, say, a bunch of geoPaints, I like to have
one workdisk with geoPaint and various support files: desk accessories, fonts,
photo and text albums.  This is the disk I shadow.  One or more data disks hold
the geoPaints themselves.  If you'll be working intensely on one application
data file at a time, a different configuration may work best for you.  After
some experimentation, you'll find what you're most comfortable with.
    Hmmm, I think this is the first time I ever ran to a two-part message.  I
really *like* using the REU with GEOS  <grin>


#: 17396 S13/The GEOS Connection
    27-Dec-88  18:52:25
Sb: #17392-#REU help needed
Fm: Bob Clemens 76337,3532
To: Ed Flinn/Sysop 76703,4032 (X)

Ed,
    As always, you've provided some good information.  I've saved your 2
messages for further study.
    "Intellectual challenge," eh? Hmmm.... Well, no one asked me to buy a
computer! <grin>

                                                                Bob


#: 17397 S13/The GEOS Connection
    27-Dec-88  18:56:38
Sb: #17396-#REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: Bob Clemens 76337,3532 (X)

Bob,
   Once you get it sorted out to your satisfaction, let me know what works for
you.  Since I'm using GEOS 64 on a 128, with a 1750, I've got more power than I
know what to do with <grin>.  The 1750 can shadow two 1541's, or else shadow
one and build one RAM, or else shadow none and build one RAM 1571, and in any
of those cases still have room to shadow the directory of the 1581!
  It is, how you say, awesome!  <big grin>


#: 17399 S13/The GEOS Connection
    27-Dec-88  21:45:09
Sb: #17397-REU help needed
Fm: Marte Brengle 76703,4242
To: Ed Flinn/Sysop 76703,4032 (X)

The thing I like best about GEOS 2.0 is that "multi-file" bit.  It's so nice to
be able to click on a bunch of things and then just move ONE icon over to the
RAMdisk icon and drop it.

Since my 1541 was off in the Twilight Zone for a while, I configured GEOS 128
to boot up with a RAM 1571.  It works real well under most circumstances, but
once in a while, the technique of copying files into the RAMdisk and then back
to another disk will scramble the directory slightly. Not enough that you can't
get a directory listing, but enough that not one file will load and run,
because there are "invisible" characters listed in the file names (visible with
a track and sector editor).  I have not yet figured out how to recover from
that one, and have lost a disk or two because of it  <<<sigh>>>

                                                       --M--



#: 17415 S13/The GEOS Connection
    28-Dec-88  14:35:38
Sb: #17396-REU help needed
Fm: Anthony Marsh 72127,2301
To: Bob Clemens 76337,3532 (X)

I have downloaded the TEXTPRINTER program and will test it this week. It is
still buggy, but may do what you want. It is a GEOS application that prints a
GEOWRITE 2.1 file using your printer's normal characters and escape codes. If
you're brave enough to try a buggy version, I might upload it next week. But
I'm hoping I can find some fixes soon. Tony

#: 17412 S13/The GEOS Connection
    28-Dec-88  14:20:10
Sb: #17382-#REU help needed
Fm: Anthony Marsh 72127,2301
To: Bob Clemens 76337,3532 (X)

I have the same setup and my early 2.0 has a buggy CONFIGURE. I can't get the
drive A shadowed. You should first select drive B as RAM1541 (after selecting
NO DRIVE). Then make sure you have DMA for reboot and MOVEDATA, which speeds up
any normal activity and keeps the REU intact for almost 20 seconds after you
power down, so you can reboot after a crash. You would then use he REU as a
RAMDISK just like a regular drive, but of course remember to copy any files to
a real disk before you turn off the power. Hope yours works out ok. Write back
if you still have trouble. Tony




#: 17426 S13/The GEOS Connection
    28-Dec-88  19:42:43
Sb: #17412-REU help needed
Fm: Bob Clemens 76337,3532
To: Anthony Marsh 72127,2301

Tony,
     I'm having no problems shadowing Drive A, and have yet to re-try using the
REU as drive B.
     My real hope is that lots of software companies will start putting out
stuff for the REU.
     Thanks for your remarks.

Bob

#: 17413 S13/The GEOS Connection
    28-Dec-88  14:22:47
Sb: #17382-REU help needed
Fm: Anthony Marsh 72127,2301
To: Bob Clemens 76337,3532 (X)

Just remembered something else. After you have it configured the way you want,
make sure you copy the new CONFIGURE to all your disks that had CONFIGURE on
them. Tony


#: 17530 S13/The GEOS Connection
    01-Jan-89  21:47:05
Sb: #17399-#REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: Marte Brengle 76703,4242 (X)

Marte,
   Ummm, if you know the directory is damaged because you can see the damage
with a sector editor, couldn't you fix it with the editor?



#: 17552 S13/The GEOS Connection
    02-Jan-89  15:13:11
Sb: #17530-#REU help needed
Fm: Marte Brengle 76703,4242
To: Ed Flinn/Sysop 76703,4032 (X)

Because I don't know what kinds of strange characters are *supposed* to be
there.  There are a lot of high-order ASCII characters that show up on the
"text" side of the display as periods.  Trying to get rid of them or replace
them leads to all kinds of problems.  And GEOS file names apparently do have
extra characters in them, somewhere along the line.  For example:

  00 00 83 0D 13 42 4F 52 44 45 52 20 53 45 54 A0  .....border set
  A0 A0 A0 A0 A0 0D 0D 01 07 57 05 12 15 31 6E 00       ....w...1N.
  00 00 83 26 08 6C 65 74 74 65 72 A0 A0 A0 A0 A0  ...&.LETTER
  A0 A0 A0 A0 A0 26 02 01 07 58 01 1B 0F 17 08 00       &...x......

This from a disk that loads and runs normally (I gave up and reformatted the
last REU-scrambled disk I discovered).  I have tried messing around with
various combinations of things and could never get anything to work right. I
probably could if I knew a bit more about how it's supposed to look, but
someone borrowed my copy of "Inside Commodore DOS" and never returned it, and I
don't remember all that stuff  <<sigh>>

                                                    --M--


#: 17554 S13/The GEOS Connection
    02-Jan-89  16:49:27
Sb: #17552-REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: Marte Brengle 76703,4242

Marte,
   You're going to need some GEOS documentation, too, since GEOS makes use of
some of the "unused" areas in the directory.  By the numbers then:

  00 00

is part of the previous entry, but is unused there, in any case

        83

is the CBM filetype, USR in this case

           0D 13

is the track and sector of the first block in the file

                 42 4F 52 44 45 52 20 53 45 54 A0
  A0 A0 A0 A0 A0

is the filename, padded with shifted spaces

                 0D 0D

is the track and sector of the GEOS info sector

                       01

is the GEOS file structure type, VLIR in this case

                          07

is the GEOS file type, Application Data in this case

                             57

is the Year portion of the date last modified, $57 = 87 = 1987

                                05

is the month portion of that date

                                   12

is the day portion, $12 = 18.  Date last modified = 05/18/87

                                      15 31

are respectively: hour and minute last modified. $15 = 21, $31= 49, time
modified = 21:49 = 9:49PM

                                            6E 00

is Intel format (lo byte, hi byte) filesize, in blocks.  $006E = 110 blocks.

  00 00

are unused


  Actually, that entry and the next both look like perfectly good GEOS files to
me.




#: 17564 S13/The GEOS Connection
    02-Jan-89  23:52:25
Sb: #17554-#REU help needed
Fm: Marte Brengle 76703,4242
To: Ed Flinn/Sysop 76703,4032 (X)

That's what I mean.  I know what all the "standard" C= stuff stands for (like
file type and address, etc) but the other stuff, who knows?  And I wasn't
looking at the numbers but rather the strange characters after the file name.
Some of the ones on the scrambled disks had additional characters like / and &
BEFORE the first letter of the filename, which prevented any of those files
from being loaded and run.  Furthermore, I could never turn past the first page
on the notepad without getting a disk error.

So, in general, not knowing what exactly that stuff is supposed to be, I
generally just give up and junk the disk.

                                                    --M--

#: 17566 S13/The GEOS Connection
    03-Jan-89  02:30:53
Sb: #17564-#REU help needed
Fm: Ed Flinn/Sysop 76703,4032
To: Marte Brengle 76703,4242 (X)

Hmmm, and that drive doesn't do anything else wierd?


#: 17579 S13/The GEOS Connection
    03-Jan-89  16:18:02
Sb: #17566-REU help needed
Fm: Marte Brengle 76703,4242
To: Ed Flinn/Sysop 76703,4032 (X)

Nope.  The "scramble" happens only occasionally, and only when I have used the
REU as drive B and have copied files into and out of it.  I have no idea what
causes it, since it doesn't seem to be consistent.  It certainly does get
frustrating to lose a disk that way, though.

                                                        --M--




#: 17657 S13/The GEOS Connection
    07-Jan-89  19:28:38
Sb: #17579-#REU help needed
Fm: John D 73455,43
To: Marte Brengle 76703,4242 (X)

Now we are getting somewhere. Your problem sounds like heat Either the REU is
drawing enough power that it is overheating (prob low) or it is drawing enough
to overheat the REU power supply (I assume you ARE using the P.S. which came
with the REU) and caussing a mix up or: The computer is overheating and causing
the mixup durning transfer or: The DISK DRIVE dosen't like to run for more than
so long (Like mine) and after a long session of GEO-WORK the drive has gotten
so hot (Even though it is not doing anything) that it is messing up the disk
(Boy do I know about that one, One of my drives, the main one does that all the
time)

Hope this helps John


#: 17660 S13/The GEOS Connection
    08-Jan-89  01:00:53
Sb: #17657-REU help needed
Fm: Marte Brengle 76703,4242
To: John D 73455,43

Good suggestions, John.  I'm using a 128 and a 1750 and a 1571, which are not
as prone to heat problems as their 64-system equivalents, but it certainly
could be a problem if the computer has been on for a long time. I'll have to
try to make sure to work in a cool environment.

                                                         --M--


#: 18294 S13/The GEOS Connection
    21-Feb-89  22:55:34
Sb: REU clips as heat sinks?
Fm: Anthony Marsh 72127,2301
To: Bob Clemens 76337,3532

The message I saw about the REU clips also acting as heat sinks was #498940
from MARV on Qlink. Another guy, Timothy B2 agreed in his #498236 that the
clips must connect with the RF shield. However, some of our local users have
been using their REUs on cartridge expanders with seemingly no problems. But a
couple of us have noticed that they did not seem to work with the Aprospand. So
I think the jury is still out on this issue. Tony


#: 18314 S13/The GEOS Connection
    23-Feb-89  19:20:01
Sb: #18294-REU clips as heat sinks?
Fm: Bob Clemens (Roch. NY) 76337,3532
To: Anthony Marsh 72127,2301

Tony,
    Whoever answered my query on CBMSERVICE mentioned only the clips being
grounding devices.  Frankly, I really don't think the REU creates any heat to
get rid of; my clips never even get warm.
    I've had no problems so far using my 1764 with my Navarone expander (3
sockets with reset button).

                                                                Bob


#: 18315 S13/The GEOS Connection
    23-Feb-89  20:09:44
Sb: #18294-REU clips as heat sinks?
Fm: Ed Flinn/Sysop 76703,4032
To: Anthony Marsh 72127,2301

Anthony,
   I've seen mention elsewhere that the Aprospand requires that the REU be
installed in the slot physically closest to the computer.  The reasons given
for this seem a little confused, and, having no expander, I can't comment on
whether or not it makes any difference.